!pr1
Modify DOS 3.3 for Big BSAVEs..............Bob Sander-Cederlof

Jim Sather (author of "Understanding the Apple II" and designer of the QuikLoader card) called today, and one topic of discussion was DOS 3.3's limit of 32767 for the maximum size of a binary file.  Jim has been blowing 27256 EPROMs, which are 32768 bytes long.  To write a whole EPROMs worth of code on disk it takes two files, because the EPROM holds one more byte than the maximum size file.

The limit doesn't apply if you write the file with the .TF directive in the S-C Macro Assembler, but it is checked when you type in a BSAVE command.  The "L" parameter must be less than 32768.

I remembered that somewhere very recently I had read of a quick patch to DOS to remove the restriction.  Where?  Hardcore Computing?  Call APPLE?  Washington Apple Pi?

The answer was "yes" to both Call APPLE and W.A.P., because Bruce Field's excellent Apple Doctor column is printed in both magazines.  The July 1984 Call APPLE, on page 55, has the answer:

!lm+5
!rm-5
"Sure, change memory location $A964 in DOS from $7F to $FF.  From Applesoft this can be done with POKE 43364,255.  This changes the range attribute table in DOS to allow binary files as large as 65535 bytes."
!lm-5
!rm+5

By the way, please do not try to BSAVE 65535 bytes on one file.  You will not succeed, because doing so will involve saving bytes from the $C000-C0FF range.  This is where all the I/O soft switches are, any you will drive your Apple and peripherals wild.  And you will not be able to BLOAD it, because it will load on top of the DOS buffers.  In general, do not BSAVE any area of RAM which includes $C000-C0FF.  Do not BLOAD into the DOS buffers or DOS variables.

If you want to test Bruce's patch, make the patch and then BSAVE filename,A$800,L$8E00.  This will save from $800 through $95FF.
